昨天我們深入探討了 Kubernetes Pod 的進階設計模式，從 Init Container 到 Multi-Container 的三個模式。透過實戰，我們了解了如何使用 Init Container 來處理啟動前的依賴檢查，確保主應用在正確的環境下啟動；看到 Sidecar 模式如何優雅地解決日誌收集問題，讓傳統應用也能輕鬆整合到雲原生架構中；實作了 Adapter 模式來轉換監控指標格式，以及 Ambassador 模式來簡化外部服務的連線複雜度。
這些設計模式展現了 Kubernetes 的強大與靈活，但也帶出了一個實務上的問題，當我們需要管理數十個相互依賴的服務，每個服務都有複雜的 Multi-Container 配置，而且還要在 Dev、Stage、Prod 等不同環境中維護不同版本的 YAML 檔案時，手動管理這些配置檔案簡直是一場災難。更別提當需要升級、回滾或是在團隊間分享這些配置時的種種挑戰。
這就是 Helm 要解決的問題。作為 Kubernetes 的套件管理器，Helm 不僅能將複雜的應用配置打包成可重複使用的 Chart，還提供了模板化、版本控制、依賴管理等強大功能。今天就要來看看 Helm 如何讓 Kubernetes 應用的部署和管理變得簡單和高效。
假設現在我們要部署一個 WordPress 網站到 Kubernetes。這樣看似簡單的應用，也需要 Deployment、Service、PersistentVolume、Secret、ConfigMap 等多個物件協同工作，每個物件都需要獨立的 YAML 檔案。當我們需要調整配置時，比如將儲存空間從預設的 20GB 改成 100GB，就要逐個開啟檔案修改；待幾個月後要升級 WordPress 版本，又要找出所有需要修改 image tag 的地方。
更麻煩的是多環境管理。開發環境只需要 5GB 儲存空間，生產環境需要 100GB，每個環境都要維護一套 YAML 檔案。當要刪除應用時，還要記住所有相關物件並一個個刪除，漏刪任何一個都會留下孤兒資源。如果把所有定義塞進一個巨大的 YAML 檔案？那會變成上千行、可讀性超差的檔案，要找特定配置如同大海撈針。
Kubernetes 本身並不理解「應用」的概念。對它來說，WordPress 只是一堆毫無關聯的獨立物件，它不知道這個 PersistentVolume、那個 Deployment 和那個 Secret 都屬於同一個應用。就像電腦遊戲包含了執行檔、音效、貼圖等數千個檔案，如果要手動下載和管理每個檔案會是一場災難，所以我們需要安裝程式來統一處理。
Helm 就是 Kubernetes 世界的「安裝程式」。它引入了 應用級別管理 的概念，把相關的 Kubernetes 物件打包成一個完整的套件。透過 helm install wordpress 一個指令，就能部署包含數十個物件的完整應用；需要升級時執行 helm upgrade；想要回滾就用 helm rollback；要刪除則是 helm uninstall，Helm 會記住所有相關物件並完整清理。
最重要的是，Helm 透過 模板化 解決了配置管理的難題。所有可自訂的設定都集中在一個 values.yaml 檔案中，我們可以在這裡定義儲存空間大小、映像版本、資料庫密碼等所有參數。不同環境只需要準備不同的 values.yaml 檔案，同一份模板就能適用於所有環境，解決了多環境配置管理的問題。
Chart 是 Helm 的核心，一個 Chart 包含了部署應用所需的所有資源定義模板、預設配置值、以及相關的元資料。當你執行 helm install 時，Helm 會讀取 Chart 的內容，根據我們的配置生成實際的 Kubernetes 資源定義，然後部署到 Cluster 中。
Chart 的結構其實很簡單。最重要的是 templates 目錄，裡面存放著所有的資源模板檔案；values.yaml 定義了所有可配置的預設值；Chart.yaml 則包含了 Chart 本身的資訊，如名稱、版本、描述等。如果應用有依賴，還會有一個 charts 目錄存放依賴的子 Chart。
wordpress/
├── Chart.yaml # Chart 的基本資訊（名稱、版本、描述）
├── values.yaml # 預設配置值
├── templates/ # 資源模板目錄
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── pvc.yaml
│ └── secret.yaml
└── charts/ # 依賴的子 Chart
Templates 是 Helm 的精髓所在。看起來像普通的 YAML 檔案，但包含了用雙大括號 {{ }} 標記的變數。例如 image: "wordpress:{{ .Values.image.tag }}" 這行，Helm 會將 {{ .Values.image.tag }} 替換成 values.yaml 中定義的實際版本號。
這種機制讓同一份模板可以適應不同的需求。開發環境可以用 values-dev.yaml 設定較小的資源；生產環境用 values-prod.yaml 設定較大的資源。模板保持不變，只需要切換不同的 values 檔案，就能部署到不同環境。
每次安裝 Chart 時都會創建一個 Release，它是 Chart 在 Kubernetes 中的一個運行實例。它讓我們可以用同一個 Chart 部署多個完全獨立的應用實例。
比如我們可以用同一個 WordPress Chart，透過不同的 Release 名稱和配置，同時部署開發版、測試版和生產版的 WordPress。每個 Release 都有獨立的生命週期，可以單獨升級、回滾或刪除，互不影響。Helm 會追蹤每個 Release 的歷史版本，讓你能夠隨時查看或回滾到之前的版本。
就像 Docker Hub 之於 Docker Image，Helm 也有專門存放 Chart 的倉庫。Artifact Hub 是最大的公共 Chart 倉庫，由社群維護。許多知名的開源專案都提供了官方的 Helm Chart，讓使用者能夠輕鬆部署。
除了公共倉庫，企業也可以建立私有 Repository 來存放內部應用的 Chart。這讓團隊能夠標準化應用部署流程，新成員只需要學習幾個 Helm 指令，就能部署複雜的內部系統。
在實戰 Helm 之前，當然要先安裝 Helm。我在 【Day22】Ingress 實戰：從 NodePort 到反向代理 因為需要安裝 Ingress Controller 所以已經安裝過了。安裝方式是透過 Helm GitHub 提供的腳本，通過 curl 的方式將腳本下載下來後，賦予其執行的權限，執行後就把 Helm 安裝好了。
# 下載安裝腳本
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 > get_helm.sh
# 授予執行權限
chmod +x get_helm.sh
# 執行
./get_helm.sh
# 測試安裝是否成功
helm version
啟用自動補全：
# 修改 .bashrc
vi .bashrc
# 加入下方指令
source <(helm completion bash)
# 載入 .bashrc
source .bashrc
安裝完成後，我們可以直接搜尋 Artifact Hub 上的 Chart。這個社群維護的 Hub 有很多個現成的 Chart 可以使用：
helm search hub wordpress
不過如果要從特定 Repository 搜尋，需要先加入該 Repository。讓我們加入 Bitnami 這個提供高品質 Chart 的倉庫：
# 加入 Bitnami repository
helm repo add bitnami https://charts.bitnami.com/bitnami
# 列出已加入的 repositories
helm repo ls
記得定期更新 Repository 的快取，確保能搜尋到最新版本的 Chart：
helm repo update
現在就能從 Repository 中搜尋 Chart 了：
helm search repo wordpress
接下來實際部署 WordPress。為了方便實戰，我們關閉持久化儲存（實際生產環境不適合這麼做）：
# 安裝 WordPress Chart
helm install my-wordpress bitnami/wordpress \
--set mariadb.primary.persistence.enabled=false \
--set persistence.enabled=false
# 查看已安裝的 Release
helm ls
可以看看看這個 Helm 指令的簡潔性。透過 --set 參數，我們可以覆蓋 values.yaml 中的預設值，而不需要修改任何檔案。Helm 自動為我們創建了所有必要的 Kubernetes 資源：
可以看到 Helm 創建了 Deployment、StatefulSet、Service、Secret 等多個資源。如果要手動管理這些資源，光是編寫 YAML 檔案就要花費不少時間，更別提後續的維護了。
有時候我們需要對 Chart 進行更多的客製化調整。這時可以先下載 Chart 到本地，使用 --untar 參數是因為 Helm Chart 大多會打包成 tar 檔：
helm pull --untar bitnami/apache
進入資料夾後，可以看到完整的 Chart 結構：
Chart 的結構非常清晰。Chart.yaml 包含 Chart 的元資料；values.yaml 定義了所有可配置的參數，例如 Replicas 數量、Service 類型、資源限制等；templates 目錄則包含了所有的 Kubernetes 資源模板。
helm install mywebapp ./apache
Service 成功部署：
相比手動管理 YAML 檔案，需要設定一堆資源的配置，使用 Helm 只需要幾個簡單的步驟就能完成複雜應用的部署。當然也可以把自己的 Service 包裝成 Helm Chart，但是這並不在 CKAD 的考試範圍，因此就暫時先不實作。
今天我們實戰了 Helm，從基本的安裝設置到實際部署複雜的應用。透過實戰可以看到，Helm 確實解決了我們在管理 Kubernetes 應用時遇到的諸多痛點。原本需要管理數十個 YAML 檔案的 WordPress 應用，現在只需要一個 helm install 指令就能完成部署；需要調整配置時，只要修改 values.yaml 或使用 --set 參數即可。
Helm 的強大之處在於它建立了一個完整的生態系統。透過 Chart 的標準化打包格式和 Repository 機制，我們可以輕鬆使用社群貢獻的應用配置，不需要從零開始就能快速部署複雜的應用。
然而，Helm 的模板化方式雖然強大，但 Go Template 語法對初學者來說可能有一定的學習門檻。而且在某些場景下，我們可能只是需要對現有的 YAML 檔案進行小幅度調整，而不需要完整的模板化功能。這就是明天要研究的 Kustomize 登場的時候。不同於 Helm 的模板化哲學，Kustomize 採用了「疊加」（Overlay）的方式，讓我們能夠在保留原始 YAML 檔案的基礎上，透過 patches 來實現配置的客製化。更重要的是，Kustomize 已經被整合進 kubectl 中，成為 Kubernetes 的原生功能。
明天我們將深入探討 Kustomize，看看它如何用完全不同的思路來解決配置管理的問題。
iThome鐵人賽
看影片追技術